Virus Labs & Distribution
VLAD #6 - Bait Detection


 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
                           Advanced bait detection

                                by CoKe/VLAD
 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ


                                Introduction:


 Bait files are the files the AV create to get them infected by a virus,
 to check out his behaviour, his polymorphism, and last but not least to
 debug it. Usually these files are pretty small, and only contain a few
 instructions (i.e. Printing a message). As soon as they start infecting
 hundreds (maybe thousands) of baits, they'll find out everything about
 the virus. So to give them a real hard time doing their jobs, every
 virus should in one way or another be able to recognize those files.

 There are many possible ways of detecting bait files; most of them are
 covered by the article 'Resist!' which you can find in this issue as well.
 Since I suppose you don't want to read all that stuff twice, I will just
 leave it out of my article.
 
 In this article I will cover another way of detecting bait files:
 code-analysis, bait-heuristics to say so, and after checking out tons
 of executables, here's what I found out:
 

 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ


                              1 - COM Baits
                              ÄÄÄÄÄÄÄÄÄÄÄÄÄ

 Detecting COM baitfiles is a bit difficult, since you really have to
 check out the code (in EXE's you can analyse the header aswell, but
 the informations below are still true for them). Since bait files are
 usually pretty small, best way to do it is to check the first 2048
 (or even 4096) bytes for some specific constructions. Below are
 listed a few things that mostly happen in bait files. Of course it's
 no 100% detection, but if some of these criteria are fulfilled together,
 it's better to make your virus ignore that file.


 - Check for massive use of INC/DEC structures (there's no point in
   increasing a register right after decreasing it :))

 i.e. : INC AX
        DEC AX
        INC BX
        DEC BX
        etc.
       

 - Check for a huge amount of NOP's (especially after jumps), since in
   "normal" COM files, there are few or no NOP's at all.

 i.e. : JMP 110
        NOP
        NOP
        NOP
        NOP
        NOP
        etc.

  Also check for huge amounts of 00h bytes after jumps.


 - Check if the first instructions are a
        mov ah, 4Ch
        int 21h sequence (same for ret)
   or if the first instruction jumps to such a routine.


 - Check for zero jumps (E90000h, EB00h etc.); again, in "normal" programs,
   usually there are no zero jumps.


 - Check for jumps to jumps. Of course this can happen in any COM file, but
   if you have a jump to a jump along with tons of NOP's, you can be sure
   there are wierd things going on.


 - Also check for calls to a ret, as this is meaningless code too.


 As I said, on their own, none of these criteria are useful. But combined
 they give kinda a bait-heuristic, and it depends on you, how you
 consider the matches. A file that matches even 3 of these criteria is
 suspicious in my eyes.


 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 
                              2 - EXE Baits
                              ÄÄÄÄÄÄÄÄÄÄÄÄÄ


 As for EXE baits, the above is still true. In addition to all that, we
 have the EXE-header that can help us.

 - Most bait files don't have a stack!
   To check this out, just compare CS with SS and SP with IP. If they both
   match there is no stack, which is quite uncommon for EXE's.

                               ÄÄÄÄÄÄÄÄÄÄÄ

                             EXE header structure
 
 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

                   Offset    Description         Size    
                   00        Signature           1 word    'MZ' or 'ZM'
                   02        Last Page Size      1 word  
                   04        File Pages          1 word  
                   06        Items               1 word  
                  *08        Header Paras        1 word  
                   0A        MinAlloc            1 word  
                   0C        MaxAlloc            1 word  
                   0E        SS                  1 word<ÄÄÄÄÄÄÄ Compare CS
                   10        SP                  1 word<ÄÄÄÄÄÄÄ to SS and
                   12        Negative checksum   1 word         IP to SP!
                  *14        IP                  1 word<ÄÄÄÄÄÄÄ
                  *16        CS                  1 word<ÄÄÄÄÄÄÄ
                   18        Reloc table offset  1 word 

    ( [*] These are needed to calculate the entry point of the EXE. )
 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

         An EXE file with no stack is definitely to be distrusted!

 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ


  For the further code-analysis, you gotta analyse the code at the
  entry point, and _NOT_ the code after the header! This is a bit more
  complicated than for the COM's, but once you got the entry point
  (file offset of the code at CS/IP), it's the same as for COM files.
  Unfortunately you won't find the entry point anywhere in the header.
  To get it, you must use the following formula:


                  ((CS + Header Para's) * 16) + IP

                  (See EXE header structure above)


 Example:
                mov ax, word ptr cs:[exeheader + 16h]   ; This loads the CS
                                                        ; to AX
                add ax, word ptr cs:[exeheader + 08h]   ; Add the header
                                                        ; para's to CS
                mov dx, 10h
                mul dx                                  ; Multiply by 16
                add ax, word ptr cs:[exeheader + 14h]   ; Add the IP


 This leaves the entry point in AX. Now all you need to do is to set the
 filepointer to the calculated address, and there you go...


                                Final words:


 By respecting the ideas mentioned in 'Resist!', and adopting some of these
 techniques, you can be pretty sure to give the AV a hard time, unless you
 want your latest virus in any AV software 2 days after it was released! :)


 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ
 ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ


- VLAD #6 INDEX -

ARTICLE.1_1      

Introduction
ARTICLE.1_2       Aims and Policies
ARTICLE.1_3       Greets
ARTICLE.1_4       Members/Joining
ARTICLE.1_5       Dist/Contact Info
ARTICLE.1_6       Hidden Area Info
ARTICLE.1_7       Coding the Mag

ARTICLE.2_1      

Resist!
ARTICLE.2_2       IBM-AV
ARTICLE.2_3       MIME Disasm
ARTICLE.2_4       Dark Fiber Tunneling
ARTICLE.2_5       Bait Detection
ARTICLE.2_6       MCB Stealth
ARTICLE.2_7       RHINCE2

ARTICLE.3_1      

Win95 Intro
ARTICLE.3_2       Win95 tute
ARTICLE.3_3       PE header format
ARTICLE.3_4       Bizatch
ARTICLE.3_5       The Boza Situation
ARTICLE.3_6       Bizatch News
ARTICLE.3_7       What's Next ?

ARTICLE.4_1      

Virus Descriptions
ARTICLE.4_2       Gilgamesh
ARTICLE.4_3       VIP
ARTICLE.4_4       SVL 1.2
ARTICLE.4_5       TFIWWB
ARTICLE.4_6       nimd00d3
ARTICLE.4_7       386 Virus

ARTICLE.5_1      

CLME Disasm
ARTICLE.5_2       Timber Wolf
ARTICLE.5_3       Serrelinda
ARTICLE.5_4       Insert v1.7
ARTICLE.5_5       Backwards
ARTICLE.5_6       TraceVir
ARTICLE.5_7       Lapis Lazuli

About VLAD - Links - Contact Us - Main